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SECTION  1 
SUMMARY 


INTRODUCTION 

This  report  covers  the  work  prescribed  in  the  task  entitled  ”MTMC 
CONUS  Movement  Scheduling  Program"  in  Contract  Number  MDA903-79-C-0172, 
The  purpose  of  this  task  order  is  to  provide  technical  assistance  to  the 
Military  Traffic  Management  Command  (MTMC)  in  the  development  of  the 
capability  for  the  analysis  and  scheduling  of  CONUS  movements  by  computer 
for  mobilization  and  deployment  planning  in  support  of  operation  planning 
or  other  special  projects.  The  full  tasking  statement  is  in  Appendix  A. 

BACKGROUND 

Deployment  Scheduling  and  Analyses 

Deployment  movement  scheduling  by  the  MTMC  is  now  based  on  MAPS 
(Mobility  Analysis  and  Planning  System),  a  computerized  simulation  system 
that  suffers  from  serious  defects  in  structure,  logic,  and  usage  (see 
Table  1).  This  situation  is  apparently  the  result  of  many  factors  in¬ 
cluding  development  of  the  original  system  concept  in  1966,  transfers  of 
system  responsibility  from  one  headquarters  to  another,  reprogramming 
from  one  computer  system  to  another,  piecemeal  efforts  to  amplify  the 
scope  of  the  system  to  be  compatible  with  evolving  JCS  planning  systems 
and  reporting  requirements.  A  detailed  account  of  the  development  of 
MAPS  is  in  Appendix  B.  The  resulting  difficulties  are  well  known,  and 
only  the  major  ones  are  stunmarized  below: 

•  Inability  to  respond  rapidly  to  planning  tasks. 

•  Inability  to  perform  mobility  analyses  of  two  or  more 
theaters  simultaneously. 

•  Large  expenditures  of  overtime  resources  in  efforts  to  meet 
planning  deadlines. 

•  Lack  of  adequate  credibility  of  the  output  of  MAPS  and  the 
manual  resolution  of  movement  requirements  not  scheduled  by 
MAPS. 

•  Inability  to  integrate  mobilization  and  deployment  movement 
planning. 
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TABLE  1 

MAJOR  DEFICIENCIES  IN  MAPS  SCHEDULING  SYSTEM 


STRUCTURAL  DEFICIENCIES 

•  Rimning  time  is  excessive  (over  18  hours). 

•  Documentation  is  incomplete  and  not  fully  understandable 

•  No  programs  for  providing  the  analyst  with  stumnary  data  for  pre¬ 
liminary  analyses  and  understanding  of  the  problems  involved  before 
scheduling  is  started 

•  Unable  to  accept  changes  to  individual  elements  without  rerunning 
the  entire  file  (e.g*,  change  in  berth  time  for  a  ship) 

•  Inflexible  programs  with  no  provision  for  interaction  with  the 
analyst  or  running  separate  parts  independently  and  consequently 
no  computer  capability  to  resolve  "flags" 

•  No  report  writer;  each  report  must  be  specifically  programmed 

•  No  programs  for  determining  earliest  possible  arrival  time  of 
"flagged"  movements 

•  No  data  base;  all  files  are  not  logically  related 
LOGIC  DEFICIENCIES 

•  Treats  each  scheduling  requirement  sequentially  as  a  separate 
problem  with  no  optimization  features  (e.g.,  no  effective  capability 
to  consolidate  shipments  either  at  origins  or  POEs  by  computer) 

•  Port  selection  criteria  minimize  use  of  land  travel,  with  consequent 
inability  to  handle  Europe-  and  Pacific-oriented  plans  concurrently 

•  No  provision  for  trade-r-off.  between  rail  and  motor  capacities  when 
both  modes  are  used  simultaneously  at  origins 

•  Assumes  that  (1)  rail  cars,  trucks,  and  ships  are  available  as 
needed;  (2)  that  there  are  no  constraints  on  holding  capacity  at 
ports,  and  (3)  that  there  is  a  fixed  time  to  load  ships  regardless 
of  cargo  to  be  loaded  and  port  facilities 

•  No  provisions  for  RO/RO  ships 
USAGE  DEFICIENCIES 

®  The  level  of  detail  treated  is  unwarranted  by  the  data.  Costly  time 
consuming  manual  effort  is  expended  on  lines  that  comprise  far  less 
than  10%  of  the  tonnage  to  be  moved 

•  No  provision  for  integrated  analyses  of  deployment  and  mobilization 
(INCONREP)  movement  requirements  (currently  treated  sequentially) 

•  Excessive  number  of  ports  and  manual  effort  used  to  resolve  "flags" 
because  MAPS  is  oriented  on  meeting  latest  arrival  date  (LAD)  with 
consequent  movement  of  many  ships  loaded  far  below  capacity. 


2 


Interface  with  Other  Transportation  Operating  Agencies 


Military  Airlift  Conmiand  (MAC) 

There  are  no  significant  interface  problems  between  the  MTMC  and 
the  MAC.  MAC  specifies  the  Air  Port  of  Embarkation  (APOE)  and  the  time 
for  the  arrival  there  of  passengers  and  cargo.  The  MTMC  responsibility 
ends  with  the  delivery  of  the  passengers  and  cargo  at  the  APOE. 

Military  Sealift  Command  (MSC) 

The  overall  current  system  for  deployment  planning  is  severely 
handicapped  by  the  division  of  responsibility  in  the  planning  for  move¬ 
ment  requirements  using  sea  transportation.  The  MTMC  is  responsible  for 
that  part  of  the  requirement  starting  at  the  origin  and  ending  with  a 
ship  loaded  by  the  MTMC  at  a  port  selected  by  the  MTMC.  The  MSC  is 
responsible  for  the  planning  that  involves  furnishing  ships  at  the  ports 
designated  by  the  MTMC  and  the  onward  movement  to  the  port  of  debarkation 
(POD).  The  interface  between  the  MTMC  and'  the  MSC  is  poor,  there  is  no 
commonality  between  their  models,  and  as  a  result,  the  MTMC  scheduling 
is  based  on  the  use  of  notional  ship  speeds  and  capacities  and  assumes 
ships  are  available  as  required. 


DISCUSSION 

A  fundamental  defect  of  the  MAPS  scheduling  system  is  the  lack  of 
any  optimization  procedures.  MAPS  is  a  pure  simulation  that  treats  each 
movement  requirement  in  turn  as  a  separate  problem.  Coupled  with  the 
lack  of  a  front-end  analysis  capability,  treatment  in  detail  beyond  that 
warranted  by  the  data,  and  rigid  planning  assumptions,  MAPS  results  in: 

•  About  20%  computerized  output  and  80%  manual  output  to 
complete  a  deployment  analysis 

•  Inability  to  cope  with  a  nxamber  of  mobility  planning  problems 
(multi-theater  plans  and  integrated  mobilization  and  deploy¬ 
ment  planning)  . 


The  lack  of  adequate  documentation  in  MAPS  precludes  any  efforts 
to  modify  the  scheduling  programs  to  remedy  the  major  defects  cited  in 
Table  1.  The  documentation  provided^  indicates  that  efforts  to  modify 
the  scheduling  programs  would  be  very  time  consuming  and  costly,  partic¬ 
ularly  in  view  of  the  logic  deficiencies  indicated  in  Table  1.  Conse¬ 
quently,  a  new  model  or  sets  of  programs  are  required  for  movement 
scheduling. 

Optimization 

Currently,  linear  programs  for  optimization  of  large  and  complex 
problems  such  as  those  addressed  by  MA.FS  are  extremely  difficult,  if  at 
all  possible,  to  formulate  and  require  very  long  times  to  run.  Further, 
the  output  of  these  linear  programs  is  difficult  to  explain. 

Recent  developments  in  the  field  of  mathematical  programming  give 
promise  of  permitting  relatively  rapid  formulation  and  solution  of  large 
problems  such  as  the  CINC  Operations  Plans  presented  to  the  MTMC.  Even 
if  a  practical  mathematical  programming  technique  can  be  found  for  an 
optimization  model  for  scheduling  movement  requirements  now  handled  by 
MAPS,  it  will  still  be  necessary  to  have  a  supporting  simulation  model 
to  produce  the  types  of  detailed  data  required  from  the  MTMC,  by  the  JCS, 
the  other  TOAs,  and  for  the  MTMC  internal  planning. 

"Front-End"  Analysis  and  Aggregation 

One  approach  to  reducing  the  number  of  movement  scheduling  require¬ 
ments  is  to  provide  the  analyst  (s)  with  (1)  stimmary  data  on  all  the 
movement  requirements  in  the  plan(s)  for  "front-end"  analysis  before 
scheduling  starts,  and  (2)  programs  for  aggregating  lines  and  FRNs  with 
small  tonnages  (level  to  be  set  by  the  analyst) .  The  provision  of  such 

^Larry  Bobo,  "System  Description  for  Mobility  Analysis  and  Planning 
System  (MAPS),"  MTMC,  1  March  1979. 

2 

Hindelang,  Thomas  J.,  and  John  F.  Muth,  "A  Dynamic  Programming  Algorithm 
for  Decision  CPM  Networks,"  Operations  Research,  March-April  1979, 
and  Glover,  F.,  J.  Hultz,  D.  Klingman  and  J.  Stutz,  "Generalized 
Networks:  A  Fundamental  Computer-Based  Planning  Tool,"  Management 
Sciences ,  August  1978. 
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sxnranary  data  and  aggregation  programs  would  permit  early  decisions  by 
the  analyst  on  movement  requirements  that  are  either  inconsequential  and 
need  not  be  scheduled  or  that  can  be  aggregated  and  still  be  within  the 
feasibility  limitation  (+  10%)  prescribed  by  the  Joint  Operation  Planning 
System  (JOPS) .  In  this  manner,  the  workload  in  terms  of  computer  running 
time  and  manual  effort  can  be  reduced. 

The  capability  to  provide  summary  data  and  aggregation  routines 
would  be  of  utility  with  any  movement  planning  system. 

Network  Analyses 

MAPS  is  a  rigid  system  that  minimizes  land  transit  (i.e.,  movement 
from  origin  to  nearest  available  port) .  There  are  transportation  modeling 
techniques  with  proven  algorithms  that  can  be  readily  modified  to  meet 
the  MTMC  movement  scheduling  needs.  These  techniques  are  based  on  de¬ 
fining  a  transportation  system  in  terms  of  links  and  nodes.  Links  repre¬ 
sent  roads,  rail  lines,  sea  routes,  and  transfer  capacities  (receive  and 
outload)  from  one  mode  to  another.  Nodes  are  used  to  represent  origins, 
POEs,  and  destinations.  The  major  advantage  of  this  type  of  representation 
is  the  proven  special-purpose  algorithms  that  permit  extremely  rapid  move¬ 
ment  scheduling  over  large  networks  (2000  links). 

These  algorithms  are  flexible  and  permit  the  analyst  to  exercise 
various  options.  As  currently  used,  they  normally  minimize  the  total 
transit  time.  Hence,  they  are  of  particular  use  in  integrated  mobility 
analysis  of  multi-theater  movement  plans.  After  suitable  modification  in 
combination  with  the  summary  data  and  aggregation  programs  previously 
described,  such  algorithms  should  eliminate  most  of  the  MAPS  major  defects 
cited  in  Table  1.  The  modified  algorithms,  referred  to  hereafter  as 
NETWORK,  would: 

•  Be  capable  of  analysis  of  both  single  and  multi-theater 
movement  plans . 

•  Integrate  mobilization  and  deployment  movement  planning 
analyses . 


•  Minimize  total  transit  time. 

•  Reduce,  if  not  eliminate  completely,  need  for  manual 
resolution  of  flags. 

•  Provide  estimated  earliest  date  of  arrival  at  the  POE  (POD) 
if  there  are  movement  constraints  and  identification  of  the 
governing  constraints. 

•  Provide  certain  interim  reports. 

The  NETWORK  algorithms  or  model  are  described  in  detail  in  Section  3. 
Modularity 

One  way  to  increase  the  responsiveness  of  MAPS  or  any  other  movement 
scheduling  system  is  to  take  advantage  of  the  relatively  independent 
nature  of  certain  types  of  movements.  For  example,  ammunition  moves  through 
dedicated  SPOEs.  The  origins  of  ammunition  shipments  are  from  dedicated 
points  except  for  three  locations.  Air  passengers  do  not  affect  an  origin's 
capability  to  receive  or  ship  by  truck  or  rail.  Scheduling  mutually 
exclusive  groups  of  movements,  such  as  ammunition,  air  passengers,  and 
cargo  should  decrease  computer  data  storage  problems  and  increase  planning 
responsiveness.  Currently  MAPS  ammvinition  and  cargo  are  scheduled  together 
in  accordance  with  certain  internal  priorities.  By  adapting  the  modular 
approach  outlined  above,  analysts  working  with  ammunition  and  cargo,  for 
example,  can  complete  their  work  independently.  There  are  no  problems 
foreseen  in  resolving  the  three  origins  common  to  ammxmition  and  cargo. 

The  modular  approach  will  be  incorporated  into  the  NETWORK  model. 

Other  significant  advantages  of  modularity  are  reduction  in  data 
storage  problems  and  increased  flexibility  in  the  use  of  available  computer 
time. 

Interface  Problems 

The  resolution  of  the  interface  problems  between  the  MTMC  and  the 
MSC  will  probably  require  an  extensive  period  of  negotiations.  Pending  the 
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resolution  of  these  problems,  there  are  several  measures  that  might  be 
taken  by  the  MTMC  to  improve  the  quality  of  deployment  planning.  These 
measures  are  discussed  below. 

The  speeds  and  capacities  of  the  notional  ships  used  by  the  MTMC 
should  be  closely  coordinated  with  the  MSC  and  consideration  given  to  the 
use  of  notional  slow  and  fast  ships.  Further,  a  notional  RO/RO  ship 
should  be  established  to  permit  planning  for  use  of  such  ships. 

The  MTMC  must  consider  the  time  and  distance  for  the  sea  leg  of 
movements  from  origin  to  POD  in  scheduling  arrivals  at  the  SPOE.  However, 
due  to  the  lack  of  complete  information  on  ship  schedules  and  types,  it 
is  questionable  whether  it  is  sound  for  the  MTMC  to  "flag”  shipments 
because  of  sea  movement  constraints  or  attempt  to  resolve  such  constraints 
by  use  of  an  excessive  number  of  ports  (berths)  and  loads  far  below  ship 
capacity.  Consideration  should  be  given  to  emphasis  on  the  movement  of 
cargo  to  ports  in  shipload  quantities  as  nearly  as  possible,  in  accord¬ 
ance  with  the  CINC  priorities  and  having  the  MSC  determine  if  the  sea 
leg  can  be  accomplished  by  the  latest  arrival  date  (LAD)  at  the  POD. 

CONCLUSIONS 

1.  The  current  methods  (MAPS  and  manual  procedure)  used  by  the 
MTMC  for  movement  scheduling  are  inefficient  and  flawed  in 
logic.  The  faults  inherent  in  MAPS  for  movement  scheduling 
are  so  great  as  to  preclude  any  effort  to  modify  the  existing 
scheduling  programs. 

2.  There  is  an  immediate  need  for  programs  to  produce  a  summary 
data  for  analysis  and  to  permit  aggregation,  at  levels  des¬ 
ignated  by  the  analyst,  of  FRNs  and  lines  with  small  tonnages 
before  the  start  of  movement  scheduling.  These  preprocessing 
programs  should  be  based  on  the  Master  Requirement  Record 
produced  by  the  MAPS  for  the  given  operation  plan(s). 
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3. 


There  is  an  immediate  need  for  a  new  and  well-documented 
movement  scheduling  program  or  model  that  is  compatible  with 
the  other  elements  of  MAPS,  JOPS,  and  the  computer  equipment 
at  the  MTMC. 

4.  Research  should  be  undertaken  to  determine  whether  recent 

advances  in  mathematical  programming  will  permit  development 
of  a  feasible  optimization  model  for  the  MTMC  movement 
scheduling  requirements.  Such  a  model  would  provide  inputs 
to  simulation  models  to  produce  the  detailed  data  required 
by  the  MTMC  for  internal  use  and  in  support  of  the  JOPS. 

RECOMMENDATIONS 

1.  A  ”Quick  Analysis  and  Aggregation"  option  to  develop  the 
programs  described  in  Conclusion  2  should  be  adopted.  This 
option  is  described  in  Section  2. 

2.  Concurrent  with  the  previous  recommendation,  a  new  movement¬ 
scheduling  model  called  NETWORK  should  be  developed.  This 
model,  described  in  Section  3,  is  built  on  existing  proven 
transportation  network  algorithms. 

3-  Research  should  be  undertaken  to  investigate  the  feasibility 

of  using  optimization  techniques  as  part  of  movement  scheduling. 
This  proposed  research  is  described  in  Section  4. 

RESOURCE  ESTIMATES 

The  estimated  resource  requirements  for  implementing  the  recommenda- 


are  listed  below; 

Option 

Calendar 

Months 

Technical 

Person-Months 

Cost 

1  Quick  Analysis 
and  Aggregation 

4 

7 

$  40,000 

2  Network 

11* 

20 

148,000 

3  Research 

3 

2 

18,000 

* 

Includes  time  for 

documentation 

after  the  model 

has  been  made 

operational. 


SECTION  2 

QUICK  ANALYSIS  AND  AGGREGATION  (QA^)  OPTION 


OBJECTIVES 

To  reduce  the  current  manual  workloads  and  decrease  the  time 
required  in  analyzing  and  testing  the  feasibility  of  operations  plans 
derived  from  the  Joint  Operations  Planning  System. 

METHOD 

The  objectives  are  to  be  accomplished  by: 

•  -  Automated  preparation  of  summary  tables  for  analysis  and 

decisions  prior  to  operation  of  the  current  MAPS  scheduling 
program  or  any  comparable  program 

•  Provision  of  an  automated  capability  to  aggregate  FPNs  and 

lines,  if  desired,  at  levels  determined  by  the  analyst 

•  Provision  of  the  capability  to  schedule  separately  the 

following  types  of  movements  under  the  NETWORK  option 

Ammunition 

Air  passengers 

Cargo  (other  than  ammunition) 

In  accomplishing  the  objectives  the  following  principles  will 

apply ; 

•  The  MAPS  Master  Requirement  Record  File  (File  ID41004B)  will 
be  preserved  at  all  times.  All  work  in  the  proposed  plan  is 
to  be  done  on  a  copy  of  the  MAPS  Master  Requirement  Record. 

•  No  change  is  planned  in  current  MAPS  logic  or  outputs  whether 
or  not  the  NETWORK  option  is  implemented  (see  Section  3). 

SUMMARY  TABLES 

GRC  will  prepare,  debug,  and  document  programs  to  produce  tables 
2-34,  outlines  of  which  are  appended.  These  tables  are  designed  to 
permit  preliminary  analysis  of  the  plan(s),  and  to  permit  analyst 


decisions  on  levels  of  aggregation  and  the  sequence  and  scope  of  the 
scheduling  to  be  performed  by  the  current  MAPS  system,  or  substitute 
system  such  as  NETWORK,  These  tables  are  briefly  described  below. 

Table  2 

Shows  the  total  movement  requirements  by  LAD  in  10-day  increments 
by  air  passengers,  and  sea  and  air  short  and  measurement  tonnage  for 
ammtinition,  unit  cargo,  and  resupply  cargo.  The  analyst  will  have  the 
option  of  specifying  a  constant  LAD  increment  for  each  run.  Additional 
cargo  categories  such  as  sea  passengers,  container  and  non-container 
ammunition  and  resupply  cargo,  etc.  will  be  included  in  the  tables  as 
required  by  MTMC, 

Tables  3-10 

These  tables  show  the  short  and  measurement  tonnages  for  the  total 
plan,  ammunition,  unit  cargo,  and  resupply  cargo  in  terms  of  origins  and 
destinations.  Separate  tables  cover  the  air  and  sea  movement  of  the 
four  groups.  Additional  cargo  categories  such  as  sea  passengers,  con¬ 
tainer  and  non-container  ammunition  and  resupply  cargo,  etc.  will  be 
included  in  the  tables  as  required  by  MTMC. 

These  tables  permit  the  analyst  to  determine,  among  other  things, 
those  sea  destinations  that  receive  an  insignificant  amount  of  tonnage 
for  the  purpose  of  the  plan.  Provision  will  be  made  to  delete  such 
destinations  from  further  consideration  in  the  planning  process,  at  the 
option  of  the  analyst.  In  the  deletion  process  the  FRNs  and  lines 
involved  will  be  printed  out  so  that  the  other  TOAs  concerned  can  be 
informed. 

Tables  11-18 

These  tables  show  the  same  data  as  above  but  in  terms  of  origins 
and  the  planned  LAD  in  10-day  increments.  The  analyst  will  have  the 
option  of  specifying  a  constant  LAD  increment  for  each  run. 
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Tables  19-26 


These  tables  show  the  same  data  as  above  but  in  terms  of  destina¬ 
tions  and  the  planned  LAD  in  lO-day  increments.  The  analyst  will  have 
the  option  of  specifying  a  constant  LAD  increment  for  each  run. 

Tables  27-34 

These  tables  provide  detailed  analyses  for  the  entire  plan,  ammu¬ 
nition,  resupply  cargo,  unit  cargo,  in  terms  of  numbers  of  FRNs  and 
lines  concerned  and  the  tonnages  associated  with  the  FRNs  and  lines  by 
origin  and  associated  destinations,  and  relation  to  the  total  tonnages 
involved.  Separate  tables  are  provided  for  sea  and  air  movement  of  each 
of  the  four  groups.  The  tables  provide  for  a  count  of  FRNs  and  lines 
and  associated  tonnages  within  the  breakout  of  up  to  and  including  10 
tons,  10.1  to  20  tons  inclusive,  and  more  than  20  tons.  These  brackets 
can  be  varied  by  the  analyst. 

These  tables  provide  a  basis  for  decisions  by  the  analyst  on  con¬ 
solidation  of  FRNs  and  lines  with  small  associated  tonnages  (10  tons  or 
less;  20  tons  or  less,  etc.). 

AGGREGATION 

The  aggregation  program  will  provide  for  aggregating  shipments  by 
category  (ammunition,  unit  cargo,  and  resupply  cargo).  This  program  will 
aggregate  shipments  with  a  common  origin  and  destination  to  a  level  spec¬ 
ified  by  the  analyst  (10  short  tons  or  20  short  tons,  etc).  The  aggrega¬ 
tion  will  be  by  LAD  up  to  the  tonnage  level  specified  by  the  analyst. 

For  example,  assume  that  ammunition  is  to  be  aggregated  to  the  10-ton 
level.  The  proposed  program  will  look  at  all  ammunition  requirements 
with  a  common  origin  and  destination  in  LAD  sequence  and  aggregate  all 
requirements  of  less  than  10  tons  until  a  sum  of  at  least  10  tons  is 
reached.  Provision  will  be  made  for  printing  out  the  subsximed  FRNs  and 
lines  and  for  updating  temporarily  the  tonnage  for  the  last  FRN  or  line 
that  caused  the  aggregation  to  equal  or  exceed  10  tons.  Provisions  will 
also  be  made  for  correcting  the  modified  FRNs  and  lines  and  inclusion  of 
the  subsumed  FRlTs  and  lines  for  inclusion  in  the  tape  for  preparation 
of  L  cards. 


MODULAR  SCHEDULING 


A  program  to  permit  scheduling  by  modules  will  be  provided.  The 
proposed  modules  are:  (1)  air  passengers,  (2)  ammunition,  and  (3)  cargo 
(including  both  unit  and  resupply) , 

This  modular  scheduling  is  based  on  the  following  assumptions: 

•  The  movement  of  air  passengers  from  any  origin  to  the  APOE  is 
by  bus  or  commercial  air  and  so  does  not  influence  the  out- 
loading  or  receipt  of  cargo  at  the  origin. 

•  The  outloading  capacity  for  ammunition  at  the  three  or  more 
origins  also  used  for  other  types  of  cargo  can  be  separated 
from  the  capacity  to  outload  other  types  of  cargo, 

•  Movement  of  unit  cargo  takes  priority  over  resupply  cargo  at 
any  given  origin. 

The  modular  program  is  basically  a  sorting  scheme  to  permit  inde¬ 
pendent  use  of  scheduling  programs  by  the  analysts  working  in  each  of  the 
areas  included  in  the  modules. 

EFFORT 

The  Analysis  and  Aggregation  program  outlined  above  can  be  developed 
to  the  point  of  implementation  in  about  4  calendar  months  using  about  7 
person-months  of  effort  at  an  estimated  cost  of  $40,000.  The  work  to  be 
accomplished  will  include: 

•  Development  and  debugging  of  programs 

•  Documentation  of  all  programs  to  include  instructions  for 
analysts 

•  Installation  on  government  equipment  and  training  of 
government  operators 
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The  above  estimates  are  based  on  the  following  assumptions: 

•  The  government  will  make  available  time  on  the  government 
equipment  on  which  the  programs  are  to  be  installed  on  a 
reasonable  turnaround  basis.  This  machine  time  will  be  at 
no  cost  to  GRC. 

•  The  government  will  furnish  to  GRC  a  classified  Master 
Requirement  Record  for  final  program  testing. 


TABLE  2 


TOTAL  PLAN  REQUIREMENTS  BY  LAD 
IN  TONS  AND  AIR  PASSENGERS^ 


_ LAD _ 

Total  0-10  11-20  21-30  ...  171-180^ 

Ammunition,  total 
Short 

Measurement 

Sea 

Short 

Measurement 

Air 

Short 

Measurement 

Unit  cargo,  total 
Short 

Measurement 

Sea 

Short 

Measurement 

Air 

Short 

Measurement 

Resupply  cargo,  total 
Short 

Measurement 

Sea 

Short 

Measurement 

Air 

Short 

Measurement 

Grand  total 
Short 

Measurement 

Sea 

Short 

Measurement 

Air 

Short 

Measurement 

Passengers,  air  (number) 


Additional  commodities  will  be  added  if  requested  by  MTMC. 
LAD  increments  will  be  specified  by  the  analyst. 


TABLES  3-10 


(TOTAL  PLAN)  (AMMUNITION)  (UNIT  CARGO)  (RESUPPLY  CARGO) 
TONNAGES,  REQUIRED  BY  ORIGIN  AND  DESTINATION^ 
(SEA)  (AIR)  MOVEMENT 


All  Des¬ 
tinations 


Destina¬ 

tion^ 


Destina- 

tion2 


Destina¬ 

tion 


n 


All  origins,  total 
Short 

Measurement 

Origin^ 

Short 

Measurement 


Origin 


Short 

Measurement 


1 


Additional  commodities  will  be  added  if  requested  by  MTMC. 


TABLE  11-18 


(TOTAL  PLAN)  (AMMUNITION)  (UNIT  CARGO)  (RESUPPLY  CARGO) 
REQUIRED  FROM  ORIGIN,  BY  LAD  IN  TONS  (SEA)  (AIR)  MOVEMENT 


_ LAD _ 

0-10  11-20  21-30  ...  171-180^ 


All  origins 
Short 

Measurement 

Origin^ 

Short 

Measurement 


Origin^ 


Short 

Measurement 


LAD  increments  will  be  specified  by  the  analyst. 


TABLES  19-26 


(TOTAL  PLAN)  (AMMUNITION)  (UNIT  CARGO)  (RESUPPLY  CARGO) 
TIME  REQUIRED  AT  DESTINATION,  TIME  PHASED 
BY  LAD  IN  TONS  (SEA)  (AIR)  MOVEMENT 


LAD 

0-10  11-20  21-30 

o 

00 

r-H 

• 

• 

All  destinations 
Short 

Measurement 

Destination^ 

Short 

Measurement 


Destination 

n 

Short 

Measurement 


1 


LAD  increments  will  be  specified  by  the  analyst. 


TABLE  27-34 


(TOTAL  PLAN)  (AMMUNITION)  (RESUPPLY  CARGO)  (UNIT  CARGO) 
TONNAGES  AND  FRNs  REQUIRED  BY  ORIGIN  AND  DESTINATION 
(SEA)  (AIR)  MOVEMENT 


All  Des-  Destina-  Destina- 
tinations  tions^^  tions^ 


Destina¬ 

tion 

n 


All  origins 
* 

FRNs  <  10*1  tons  (number) 

FRNs  <  10,1  tons  (tons) 

FRNs  10.1-20.0  tons  (number) 
FRNs  10.1-20.0  tons  (tons) 
FRNs  >  20.0  tons  (number) 

FRNs  >  20.0  tons  (tons) 

All  FRNs  (number) 

All  FRNs  (tons) 

%  FRNs  <  10.1  (number) 

%  FRNs  <  10.1  (tons) 

%  FRNs  i 0.1-20.0  tons  (number) 
%  FRNs  10.1-20.0  tons  (tons) 


Origin^ 


Same  as  above 


Origin^ 


Same  as  above 


or  lines 


(Note;  The  values  in  the  stub  for  sorting  by  tonnages  can  be  varied 
by  the  analyst.) 


SECTION  3 

NETWORK  MODEL  OPTION 


GENERAL  DESCRIPTION 

A  model,  to  be  called  NETWORK,  is  proposed  to  perform  the  movement 
scheduling  now  performed  by  MAPS.  NETWORK  will  be  adapted  from  proven 
existing  transportation  movement  algorithms  to  eliminate  most  of  the 
defects  in  the  MAPS  scheduling  programs  that  are  listed  in  Table  1. 

The  existence  of  these  proven  algorithms  permits  the  development  of 
NETWORK  rapidly  and  at  low  cost  as  compared  to  development  of  a  com¬ 
pletely  new  movement  scheduling  model.  The  advantages  and  disadvantages 
of  NETWORK,  as  compared  to  MAPS  scheduling  system,  are  listed  in 
Table  35. 

NETWORK  will  be  compatible  with  the  Quick  Analysis  and  Aggregation 
programs  described  in  Section  2.  The  efficiency  of  NETWORK  will  be 
improved  if  the  aggregation  programs  are  used.  The  expected  efficiencies 
are  reduced  running  time,  reduced  requirements  for  core  storage,  and 
greater  flexibility  in  the  use  of  NETWORK  by  modular  movement  scheduling 
(e.g.,  air  passengers,  ammunition,  and  other  cargo). 


TABLE  35 


MAJOR  ADVANTAGES  AND  DISADVANTAGES  OF  NETWORK 
AS  COMPARED  TO  MAPS  SCHEDULING 


STRUCTURAL  ADVANTAGES 

•  Computer  running  time  significantly  reduced  (about  8  hours  for 
60,000  movement  requirements) 

•  Schedules  either  single  or  multi-theater  movements  in  one  run 

•  Schedules  both  mobilization  and  deployment  movements  either 
separately  or  in  combination 

•  Provides  the  earliest  day  of  arrival  at  the  POD  without  vio¬ 
lating  any  throughput  or  availability  constraints  for  movements 
that  cannot  meet  the  LAD 

•  Can  store  intermediate  information  during  a  run  to  permit 
additional  requirements  on  subsequent  runs  to  be  included  in 
final  tables.  Correction  of  previously  moved  requirements 
may  require  rerunning  of  entire  module  or  plan  to  produce 
correct  tables 

•  Identifies  specific  constraints  that  prevent  arrival  at  POD 
by  LAD 

•  Can  produce  interim  reports 

m  Can  cycle  notional  ships  for  second  trips  given  availability 
at  first  port  (if  current  assumptions  on  ship  availability 
are  to  be  varied  and  explicit  availability  data  are  not 
available) 

•  Provides  a  capability  to  vary  total  availability  of  resources 
(e.g.,  ships,  rail  cars,  etc.)  to  perform  the  movement  of 
requirements 

LOGIC  ADVANTAGES 

•  Provides  for  minimum  transit  time  through  a  set  of  preferred  POEs 

•  Provides  for  trade-off  between  rail  and  motor  capabilities  when 
both  modes  are  used  simultaneously  at  origins 

•  Constrains  ports  in  terms  of  daily  ship  loading  capacity  by 
type  of  ship  (e.g.,  break  bulk,  container,  RO/RO,  etc.) 

USAGE  ADVANTAGES 

•  Warnings  (flags)  can  either  be  resolved  when  they  occur  in  the 
scheduling  sequence  or  with  residual  resources,  as  specified  by 
the  analyst,  to  estimate  arrival  date  at  the  destination 

DISADVANTAGES 

•  Requires  a  new  data  base  derived  from  data  in  the  Master  Require¬ 
ment  Record  and  the  MTMC  planning  factors 

•  Requires  large  amounts  of  core  unless  modularity  (air  passengers) 
ammunition,  etc.)  is  instituted.  Without  modularity  about 
75,000  words  of  core  required  for  a  large  90-day  plan.  With 
modularity,  core  requirements  reduced  to  about  40,000  words 


BASIC  METHODOLOGFY 

NETWORK  is  based  on  the  analysis  of  a  transportation  system  defined 
in  terms  of  links  and  nodes.  As  explained  in  Section  1,  there  are  proven 
algorithms  for  such  networks  that  can  be  adapted  to  meet  the  MTMC  needs 
for  mobilization  and  deployment  movement  analyses.  A  type  network  is 
shown  in  Figure  1. 

The  algorithms  are  used  to  determine  the  optimum  path  (least  time) 
from  origin  to  destination  without  violating  the  specified  constraints 
of  the  system.  The  constraints  to  be  incorporated  into  the  NETWORK  model 
will  include,  but  not  be  limited  to: 

•  Maximum  daily  transfer  capability  to  include  trade-off 
between  elements  of  mixed  modes 

•  Maximum  daily  link  capacity,  if  any 

•  Ship,  rail,  and  truck  capacities  (cargo  and  speeds)  and 
availability 

m  Ready-to-load  dates 

The  output  of  the  algorithms  is  the  optimal  arrival  time  at  the 
destination  for  each  movement  requirement.  In  the  NETWORK  model  the 
destination  will  be  defined  as  either  the  Air  POE,  Sea  POD,  or  mobiliza¬ 
tion  station. 

The  NETWORK  algorithms  will  be  programmed  in  FORTRAN  to  take 
advantage  of  the  language’s  efficiency  in  performing  mathematical  cal¬ 
culations  and  to  capitalize  on  the  existing  FORTRAN  programs. 

The  NETWORK  model  can  be  programmed  for  either  batch  or  interactive 
operation  assuming  the  computer  equipment  is  available.  If  the  MTMC 
wants  rapid  computer  turnaround  to  develop  schedules  as  quickly  as 
possible,  then  provision  must  be  made  for  the  modification  of  data, 
by  the  analyst,  through  terminals.  These  terminals  could  be  either  hard 
copy  or  cathode-ray  tubes  depending  on  disposition  of  the  output. 


It  is  recommended  that  the  model  be  run  interactively  or  with 
remote  job  entry  so  that  the  analyst  can  provide  immediate  gross  direc¬ 
tion  to  the  model  leaving  the  detailed  directions  (through  data)  to  be 
entered  off  line  at  the  convenience  of  the  analyst.  The  system  will  not 
succeed  if  the  analyst  must  sit  at  a  terminal,  while  the  program  is 
running,  and  answer  a  large  number  of  questions  about  the  minor  deci¬ 
sions  that  the  model  will  have  to  consider.  The  proper  time  to  plan 
the  deployment  is  before  the  run  has  started  not  during  the  execution. 

OUTPUTS 

Outputs  from  the  NETWORK  model  will  be  held  to  the  minimum  essen¬ 
tial  volume  to  reduce  the  burden  on  the  analyst.  However,  the  model 
can  produce  vast  amounts  of  data  which  can  be  stored  for  the  production 
of  special  reports*  The  first  phase  of  the  installation  of  the  NETWORK 
model  will  not  include  the  production  of  special  reports.  After  the 
MTMC  analysts  gain  experience  with  the  model,  they  will  be  in  a  better 
position  to  determine  which  special  reports  are  required  to  accomplish 
their  tasks.  Special  tables  can  be  programmed  in  FORTRAN  or  COBOL  as 
desired  or  consideration  can  be  given  to  the  use  of  the  Report  Program 
Generator  (RPG)  for  the  Honeywell  computer.  The  RPG  is  a  general- 
purpose  report  production  program  which,  if  available,  can  probably 
produce  the  special  reports  when  needed. 

The  minimum  output  from  the  model  will  consist  of  the  three  reports 
shown  in  Figure  2.  These  reports  are  described  below. 

Movement  Summary 

This  report  is  designed  to  provide  the  required  data  for  cards. 
It  will  consist  of  the  results  of  the  scheduling  run  plus  additional 
information  from  the  Master  Requirement  Record  to  provide  the  analyst 
with  a  summary  report  of  the  results  of  the  scheduling  process.  The 
report  will  contain,  as  a  minimum,  the  data  listed  below. 


Report  1 

MOVEMENT  SUMMARY 


FRN  AVAIL 


LINK  FROM 
NO.  NODE 


VEHICLE 
NO.  NAME 


DEPART  ARRIVE 

ORIGIN  ORIGIN  SPOE  SPOE  PEST. 


Report  2 

RESIDUAL  LINK  CAPACITIES 


TO  DAY 

NODE  1 

2  3  4  5  - 

Report  3 

VEHICLE  REQUIREMENTS 

DAY 

1 

2  3  4  5  -  ■ 

ARRIVE 

DEST. 


Figure  2.  Minimum  Reports  from  the  NETWORK  Model 


FKN 

AVAIL 

ORIGIN 

DEPART  ORIGIN  - 

SPOE 

ARRIVE  SPOE 
BEST 

ARRIVE  BEST 

NOTE 


the  FRN  or  line  number  of  the  movement  requirement 

the  Ready-to-Load  day  of  the  movement 

the  geolocation  code  and  name 

the  day  the  movement  is  scheduled  to  clear  the 
origin 

the  geolocation  code  and  name  (if  movement  by  sea) 
the  day  of  arrival  at  the  SPOE 

the  geolocation  code  and  name  of  the  mobilization 
station,  APOE  or  SPOD 

the  day  of  arrival  at  the  destination  as  defined 
above 

indicator  of  delays  in  the  movement  which  might 
cause  the  movement  to  be  flagged  by  MSG 


Additional  information  from  the  Master  Requirement  Record  may  be 
added  to  improve  the  value  of  the  report  for  the  analyst. 


Residual  Link  Capacities 

At  a  minimum,  this  report  will  provide  the  daily  residual  capacity 
at  the  origin  and  port  links  of  the  network  after  all  movement  require¬ 
ments  have  been  scheduled.  Since  all  origin  and  port  constraints  are 
expressed  as  link  capacities,  this  report  will  allow  the  analyst  to 
determine  bottlenecks  in  the  system.  Link  capacity  will  be  expressed  in 
terms  of  rail  cars,  trucks,  tonnages  (by  type)  as  specified  by  the  MTMC 
during  the  model  design.  The  MTMC  will  be  requested  to  determine  during 
the  model  design  if  the  output  should  be  suppressed  for  links  that  were 
not  used  or  used  only  below  a  specified  capacity.  Such  a  specification 
would  contribute  to  maintaining  the  volume  of  the  output  to  a  useful 
level.  The  report  will  contain  the  data  listed  below. 


LINK  NO. 


FROM  NODE 


TO  NODE 


DAY 


-  the  link  number  assigned  by  the  NETWORK  program. 
Link  numbers  are  assigned  sequentially  from  1  to 
the  number  of  links  in  the  network 

-  the  geoloeati-on  code  of  the  node  at  the- beginning 
of  the  link 

-  the  geolocation  code  of  the  node  at  the  end  of 
the  link 

-  the  residual  capacity  by  day  (in  terms  to  be 
specified  by  the  MTMC) 


Vehicle  Requirements 

This  report  will  show  the  number  of  vehicles  by  type  and  by  day 
which  are  required  to  meet  the  total  schedule  produced  by  the  model. 
Vehicle  constraints  (in  terms  of  maximtim  available  vehicles  per  day)  may 
be  applied  to  the  scheduling  process  if  desired. 

VEHICLE  NO.  -  The  vehicle  class  number  as  shown  in  Table  36, 

VEHICLE  NAME  -  The  name  of  the  vehicle  class  as  shown  in  Table  36. 
DAY  “  The  number  of  vehicles  used  during  that  day 


TABLE  36 

MODES  AND  VEHICLES 


Mode 

Origin  loading 

-  rail 

Origin  loading 

-  highway 

Transportation 

-  rail 

Transportation 

-  highway 

Transportation 

-  sea 

Port  constraint 

-  break  bulk 

Port  constraint 

-  container 

Port  constraint 

-  RO/RO 

Vehicle  class 
Rail  loading 
Highway  loading 
Fast  train;  slow  train 
Fast  truck;  slow  truck;  bus 
Notional  ship 
Break  bulk  loading 
Container  loading 
RO/RO  loading 


INPUTS 


The  NETWORK  model  does  not  require  any  more  data  than  the  current 
MAPS  system.  However,  the  data  must  be  structured  differently  to  take 
advantage  of  the  network  analysis  technique.  Thus,  the  network  requires 
links  of  the  proper  mode,  length,  from  and  to  nodes,  and  capacity  to 
represent  the  data  now  contained  in  tables  or  calculated.  Examples 
of  such  data  are  distances  from  origins  to  ports,  sea  distances,  origin 
throughput  constraints,  port  throughput  constraints,  etc.  Consequently, 
effort  will  have  to  be  devoted  to  programming  a  preprocessor  to  abstract 
data  from  the  current  or  new  data  bases  and  reformat  it  into  a  network 
for  input  to  the  model. 

Network 

Figure  1  shows  a  portion  of  the  network  representation  of  the 
deployment  scheduling  problem.  All  locations  with  constraints  (origins 
and  SPOEs)  are  represented  by  two  nodes  with  the  constraint (s)  shown 
as  a  link  between  them.  Thus,  the  origin  is  shown  with  rail  and  high¬ 
way  links  to  represent  loading  constraints  while  the  SPOEs  are  shown 
with  cargo-loading  constraints  for  break  bulk,  container,  and  RO/RO 
ships.  The  allowable  POEs  for  each  origin  are  designated  by  the  exist¬ 
ence  of  a  link  from  the  origin  to  the  POE.  The  absence  of  a  link 
between  nodes  prevents  movement  between  those  nodes.  In  a  similar 
manner,  the  absence  of  a  link  of  a  particular  mode  between  two  nodes 
prevents  movements  on  that  mode  between  the  nodes  in  questions.  For 
example,  if  there  is  only  a  highway  link  (no  rail  link)  between  an 
origin  and  a  POE,  no  rail  movement  can  be  made  between  those  nodes. 

Since  the  model  determines  the  fastest  time  between  origin  and 
destination,  allowable  POEs  for  both  a  European  and  Asian  deployment 
should  be  included  in  the  network.  The  model  will  then  be  able  to 
handle  multiple  theaters  during  the  same  run,  always  selecting  the 
fastest  route. 


If  links  are  also  shown  between  home  stations  and  mobilization 
stations ,  the  network  will  handle  the  mobilization  either  separately  or 
in  combination  with  the  single  or  multiple  theater  deployment. 

As  previously  stated,  the  network  consists  of  links  and  nodes. 

Links  are  explicitly  defined;  nodes  are  implied  from  the  descriptions 
of  the  links.  Each  link  is  defined  in  terms  of  the  following  data: 

•  Mode  -  one  of  the  modes  selected  from  among  those  shown  in 
Table  36 

•  Length  -  the  length  of  the  link  in  miles 

•  Capacity  -  the  maximxam  permitted  flow  over  the  link  either 
in  tons  or  vehicles  per  day.  A  link  has  infinite  capacity 
if  it  cannot  constrain  movements 

•  From  node  -  the  node  at  the  entrance  of  the  link  (geolocation 
code) 

9  To  node  -  the  exiting  node  (geolocation  code) 

«  Node  coordinates  -  these  may  be  used  to  calculate  the  length 
of  the  link  (optional) 

•  Identification  -  a  unique  link  identification  code  (optional) 
Movement  Requirements 

The  movement  requirements  for  the  network  model  will  be  abstracted 
from  the  Master  Requirement  Record  prepared  by  the  MTMC  from  the  opera¬ 
tions  plan  and  the  JOPS  data  base.  The  minimum  data  requirements  are: 

•  Ident  -  a  unique  identification  of  the  movement  requirement 

•  Origin  -  expressed  as  a  geolocation  code.  Must  have  appeared 
on  at  least  one  link 

•  Destination  -  expressed  as  a  geolocation  code.  This  data 
item  might  be  a  POD  or  mobilization  station  depending  on  the 
type  of  run.  Must  have  appeared  on  at  least  one  link 
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•  Ready  to  load  date  -  the  earliest  day  the  movement  is 
available  for  loading  at  its  origin 

•  Mode  -  the  desired  mode(s)  and  means  for  movement  from 
origin  to  destination 

•  Earliest  arrival  date  the  movement  is  permitted  at 
destination 

Parameters 

Parameters  are  used  to  describe  the  transportation  system  in  the 
detail  required  by  the  model.  These  include: 

•  Vehicle  speeds  -  the  speed  at  which  vehicles  move  over  the 
network  in  miles /day 

•  Vehicle  capacity  -  in  tons /vehicle.  Used  for  conversion 
from  tons  to  number  of  vehicles:  for  Pax;  people/vehicle 

•  Vehicle  assignment  -  assigns  vehicles  to  modes  (see  Table  36) 

•  Vehicle  constraints  -  the  number  of  each  class  of  vehicle 
available  for  the  movement  scheduling 

•  Modification  -  modifications  to  vary  the  link  capacities 
and/or  number  of  vehicles  by  day 

LOGIC 

At  least  two  programs  will  be  required  to  perform  the  scheduling; 
a  Preprocessor  and  the  NETWORK  model.  A  brief  description  of  the  logic 
of  each  follows: 

Preprocessor 

The  Preprocessor  will  be  designed  to  create  the  network  and  move- 
ment  requirements  files  from  data  readily  available  to  MTMC  and  with 
little  human  intervention. 

Network.  The  properties  for  the  definition  of  links  have  previously 
been  listed.  They  will  be  obtained  as  follows: 


•  Mode  -  One  of  the  loading,  transportation,  or  constraint 
modes  listed  in  Table  36. 

•  Length  -  The  length  of  each  link  will  be  obtained  from  either 
distance  tables  or  calculated  from  the  coordinates  of  the 
endpoint  nodes.  Distances  will  be  required  between  origins 
and  their  allowable  ports  and  between  seaports  as  a  function 
of  the  transportation  mode.  Constraint  links  will  have 
either  a  zero  or  nominal  length  depending  on  whether  or  not 

a  delay  is  desired  at  the  node. 

•  Capacity  -  Obtained  from  each  origin’s  loading  constraints 
by  day  and  transportation  mode  and  for  each  port  by  day  and 
type  of  ship.  The  units  of  capacity  will  either  be  tons  or 
vehicles  per  day. 

•  Nodes  -  Geolocation  codes  associated  with  link  end  nodes  will 
be  obtained  from  the  data  used  to  determine  the  length  of  the 
link. 

Movement  Requirements.  The  data  required  for  each  movement  require¬ 
ment  have  previously  been  defined.  They  will  be  created  as  follows: 

•  Identification  -  Will  be  obtained  from  the  Master  Requirement 
Record.  Either  the  FRN  or  line  number  will  be  used, 

•  Origin  -  Obtained  from  the  Master  Requirement  Record. 

•  Destination  -  Obtained  from  the  Master  Requirement  Record. 

•  Ready  to  load  date  -  Obtained  from  the  Master  Requirement 
Record. 

•  Mode  -  the  NETWORK  model  requires  the  designation  of  mode 
in  terms  of  the  numbers  of  vehicles  (or  tonnage)  of  each 
vehicle  class  allowed  to  carry  the  movement.  The  vehicle 
classes  are  shown  in  Table  36.  Each  movement  requirement 
must  be  permitted  to  move  on  more  than  one  vehicle  class 
in  order  to  find  an  optimum  (or  any)  path  between  its 
origin  and  destination.  The  following  data  items 


®  contained  in  the  Master  Requirement  Record  will  be  used  to 

designate  the  allowable  vehicle  classes:  the  distance 
between  the  origin  and  the  port,  the  commodity  type,  the 
specified  mode  and  means,  the  tonnage  to  be  moved,  and 
#  other  items  as  may  be  required. 

•  No-sooner-than-date  -  The  EAD  from  the  Master  Requirement 
Record. 


*  For  example,  suppose  the  requirement  is  to  move  100  tons  of  ammuni¬ 
tion  from  CONUS  origin  to  an  overseas  destination  by  sea.  The  requirement 
may  move  by  rail  or  highway  to  the  SPOE.  The  following  vehicle  types 
will  be  required. 

• 

Origin  loading.  Rail  will  be  permitted.  The  movement  requirement 
consumes  2.5  units  of  origin  loading  capacity  if  each  rail  car  holds  40 
tons.  Highway  will  also  be  permitted.  Five  units  of  highway  loading 
®  capacity  will  be  consumed  if  each  truck  holds  20  tons.  The  specification 

of  the  number  of  tons  per  vehicle  is  done  in  the  parameters  section  of 
the  input  to  NETWORK. 


•  Transportation.  If  the  movement  to  the  optimum  port  is  less  than 
700  miles,  it  will  be  by  fast-moving  truck  because  the  tonnage  is  greater 
than  a  truckload.  Or  if  the  distance  to  the  optimum  port  is  greater  than 
700  miles  it  will  move  at  less  than  trainload  speed  (slow  train)  by  rail. 

#  Both  options  must  be  allowed  since  the  length  of  the  optimum  route  is 
unknown  until  the  NETWORK  model  is  run.  Ship  travel  time  must  also  be 
allowed  because  the  movement  is  permitted  to  move  by  sea. 


#  Port  constraint .  The  vehicles  specified  will  depend  on  the  data 

in  the  Master  Requirement  File.  If  the  ammunition  is  containerized  it 
will  be  permitted  to  use  the  container  vehicle;  otherwise  it  must  use 
the  break  bulk  vehicle. 
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In  this  example,  at  least  six  vehicle  classes  were  permitted  based 
on  the  parameters  of  the  movement  requirement.  Different  movements 
will  have  different  allowable  vehicle  classes.  For  example,  the  movement 
of  tracked  vehicles  by  highway  would  not  be  permitted  regardless  of  the 
distance  to  the  port.  The  movement  of  people  by  bus  would  not  be  con¬ 
strained  by  the  loading  capability  of  its  origin  because  people  load 
themselves. 

NETWORK  provides  analytical  capabilities  for  the  MTMC  which  are 
now  lacking.  Suppose  a  movement  were  permitted  to  move  either  by  break 
bulk  or  container  classes  and  the  two  ship  classes  were  available 
(notional  break  bulk  and  notional  container) ,  then  the  model  would 
decide  which  ship  class  to  use  based  on  its  speed,  the  remaining  capac¬ 
ity  of  the  port  to  load  the  class  of  ship  and  the  availability  of  ships 
of  the  proper  class.  Thus,  the  model  would  not  only  select  the  best 
port  but  would  decide  whether  the  cargo  should  be  containerized  or  break 
bulk,  all  without  violating  any  of  the  prescribed  constraints  of  the 
transportation  system, 

NETWORK  Model 

This  portion  of  the  report  is  designed  to  provide  some  insights 
into  the  logic  of  the  NETWORK  model  as  currently  conceived.  Changes  to 
the  logic  described  will  be  required  to  meet  the  special  needs  of  the 
MTMC  as  determined  during  the  model  design. 

•  PARAMETERS  -  The  parameters  portion  of  the  input  is  read, 
stored,  and  printed  for  reference  by  the  analyst. 

•  LINKS  -  The  links  which  comprise  the  netwark:  are  read,  and 
their  transit  time  calculated.  All  links  are  checked  for 
valid  data  and  printed,  possibly  with  an  error  message. 

All  links  meeting  the  validity  checks  are  numbered 
sequentially.  This  is  the  link  nximber  which  will  be  used 
by  the  model  in  outputs  which  make  reference  to  a  partic¬ 
ular  link. 


SETUP  -  the  link  data  are  sorted  and  various  pointers  set 
to  reduce  the  time  needed  to  determine  the  least  time  path 
from  origin  to  destination. 

MOVEMENT  -  Movement  requirements  are  read  one  at  a  time; 
until  the  end  of  file  is  reached.  Control  passes  to  PATH 
except  after  the  reading  of  the  last  movement  when  control 
passes  to  POST. 

PATH  -  Movement  data  are  checked  for  validity.  Some  of  the 
checks  include  the  occurrence  of  the  origin  and  the  destina¬ 
tion  in  the  nodes  of  the  network,  and  flow  requirements 
greater  than  zero.  The  algorithm  is  initialized,  and  the 
Dijkstra  method  is  used  to  determine  the  optimum  path 
between  the  origin  and  destination  without  violating  any 
of  the  constraints  of  the  transportation  system. 

PUSH  -  Some  or  all  of  the  movement  is  pushed  along  the  optimum 
path,  adjusting  the  link  capacities  and  numbers  of  vehicles 
used.  The  amount  moved  may  be  less  than  the  total  require¬ 
ment  because  of  a  binding  constraint,  i.e.,  the  origin  capa¬ 
city  to  load  trucks  has  been  exhausted.  If  the  movement  is 
finished  then  one  line  of  the  Movement  Summary  report  is 
created  and  control  passes  to  MOVEMENT.  If  the  total  tonnage 
of  the  current  movement  requirement  has  not  been  completed , 
then  control  passes  to  PATH. 

POST  -  At  this  point  all  the  movements  have  been  completed. 

The  three  reports  previously  described  (Movement  summary. 
Residual  Link  Capacity,  and  Vehicle  Requirements)  are  created 
and  printed.  A  portion  of  the  core  is  saved  to  permit  con¬ 
tinuation  of  the  run  at  a  future  time  when,  perhaps, 
additional  movement  requirements  are  ready  for  processing. 

By  this  technique  additional  runs  can  be  made  with  the 
assurance  that  all  tables  will  be  correctly  updated,  taking 
into  account  the  additional  movements. 


BERTHING 


Assigning  cargo  to  individual  berths  within  a  port  is  not  performed 
during  deployment  planning  by  the  NETWORK  model.  This  phase  of  the 
problem  is  more  properly  done  during  execution  planning  based  on  the 
amount  and  type  of  cargo  flowing  through  a  port  on  a  given  day.  This 
type  of  output  will  be  available  from  the  NETWORK  model. 

Assigning  cargo  to  berths  is  now  required  because  in  MAPS  ships 
are  underloaded  when  they  have  to  leave  their  berths  at  the  end  of  their 
time  on  berth  period.  Thus,  manual  adjustments  must  be  made  to  try  to 
fill  ships  and  the  remaining  berth  capacity  must  be  known. 

The  problem  of  underloaded  ships  will  be  treated  in  the  NETWORK 
model  by  reducing  the  numbers  of  POEs  and  berths  available  for  the  move¬ 
ment  of  cargo.  It  appears  that  MTMC  uses  all  available  ports  for  the 
movement  of  cargo,  thus  scattering  their  movements  in  bits  and  pieces  in 
an  effort  to  meet  LADs  at  the  expense  of  reasonable  shiploads.  Reducing 
the  niimber  of  ports  to,  perhaps,  the  CINC's  desired  ports,  the  designa¬ 
tion  of  consolidation  ports,  and  the  use  of  aggregation  programs 
described  in  Section  2,  should  increase  the  daily  flow  through  each 
port,  thus  giving  a  higher  probability  of  meeting  minimum  ship  loads. 
Experiments  should  be  performed  to  determine  the  maximum  number  of 
ports  needed  to  provide  reasonable  ship  loads  at  levels  specified  by 
the  MTMC,  perhaps  in  coordination  with  the  MSC. 


EFFORT 

It  is  estimated  that  the  NETWORK  model  can  be  developed,  installed, 
and  dociamented  in  about  11  calendar  months  (20  person-months)  at  a  cost 
of  approximately  $148,000. 

In  the  sequence  of  work,  priority  would  be  given  to  the  Preproces¬ 
sor  program  data  requirements,  modification  of  existing  algorithms  and 
installation  of  the  NETWORK  model.  It  is  estimated  that  the  MTMC  could 
have  a  working  version  of  the  model  in  about  6  calendar  months  after 
award  of  contract.  This  would  permit  the  use  of  the  model,  under 


supervision  of  GRC,  for  testing,  familiarization,  and  actual  movement 
scheduling-  The  remaining  effort  will  be  devoted  primarily  to  the  doc¬ 
umentation  of  the  Preprocessor  and  NETWORK  programs  and  the  training  of 
the  MTMC  personnel. 

The  estimate  is  based  on  the  following  assumptions: 

•  Approximately  350  connect  hours  on  the  MTMC  computer 
will  be  provided  at  no  cost  to  GRC,  in  the  xmclassified 
mode.  The  work  can  be  expedited  if  the  computer  can  be 
accessed  through  telephone-connected  terminals. 

•  The  documentation  will  consist  of  user’s  manuals  and 
detailed  logic  and  program  descriptions.  The  doctamenta- 
tion  standards  will  be  established  in  coordination  with 
the  MTMC.  It  is  anticipated  that  WWMCCS  standards  will 
be  a  prime  candidate  for  consideration. 

•  The  costs  include  installation  on  government  equipment 
and  training  of  the  analysts  who  will  be  using  the 
programs. 

•  The  costs  do  not  include  special  reports  which  may  be 
desired  by  the  MTMC  beyond  those  mentioned  in  the  des¬ 
cription  of  the  NETWORK  model. 

•  The  MTMC  will  provide  an  unclassified  portion  of  a 
typical  Master  Requirement  Record  file. 


SECTION  4 
RESEARCH  OPTION 


BACKGROUND 

The  MAPS  program  and  the  suggested  NETWORK  model  are  both  simulations 
that  treat  each  movement  requirement  sequentially  in  accord  with  certain 
criteria  and  constraints.  In  the  NETWORK  model  the  concept  of  the  opti¬ 
mization  of  individual  movement  schedules  (least  time)  is  introduced  in 
an  attempt  to  produce  better  schedules.  The  research  option  takes  the 
scheduling  process  one  step  further  by  attempting  to  optimize  (least  time) 
all  the  movement  requirements  within  a  single  total  movement  schedule. 

Thus,  the  technique  will  be  able  to  evaluate  the  interactions  between 
movement  requirements  which  neither  MAPS  nor  NETWORK  can  accomplish. 
Remember  that  all  optimization  is  no  better  than  the  data  being  used. 

Currently,  linear  programming  models  for  the  optimization  of  large 
and  complex  problems  such  as  those  addressed  by  MAPS  and  NETWORK  are 
extremely  difficult  to  formulate,  if  at  all  possible,  and  require  very 
long  computer  run  times.  Further,  the  solutions  are  difficult  and  time- 
consuming  to  decipher  because  of  the  encoding  of  the  data,  and  the  ag¬ 
gregation  of  movement  requirements.  In  order  to  reduce  the  complexity 
of  the  model,  movement  requirements  are  aggregated  into  as  few  commodities 
as  possible  without  destroying  the  validity  of  the  model. 

There  have  been  recent  developments  in  the  field  of  mathematical 
programming  that  give  promise  of  permitting  relatively  rapid  formulation 
and  solution  of  large  problems  such  as  the  CINC  Operation  Plans  presented 
to  the  MTMC.  Examples  of  such  recent  developments  have  been  reported  in 
operations  research  literature.^  Even  if  a  practical  mathematical 

^Hindelang,  Thomas  J.,  and  John  F.  Muth,  "A  Dynamic  Programming  Algorithm 
for  Decision  CPM  Networks,”  Operations  Research,  March-April  1979,  and 
Glover,  F.,  J.  Hultz,  D.  Klingman,  and  J.  Stutz,  "Generalized  Networks: 

A  Fundamental  Computer-Based  Planning  Tool,"  Management  Sciences, 

August  1978. 
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prograinming  technique  can  be  found  for  an  optimization  model  for 
scheduling  movement  requirements  now  handled  by  MAPS,  it  will  still  be 
necessary  to  have  a  supporting  simulation  model  to  produce  the  types 
of  detailed  data  required  from  the  MTMC  by  the  JCS  and  for  internal 
planning  by  the  MTMC.  This  simulation  model  would  be  based  on  the  output 
of  the  optimization  model  and  would  probably  be  simpler  and  faster  than 
either  MAPS  or  even  the  proposed  NETWORK  model.  For  example,  if  the 
MTMC  wants  to  report  the  arrival  date  of  a  particular  ammunition  FRN, 
there  must  be  some  disaggregation  methodology  for  identifying  the  FRN 
from  the  solution.  A  similar  situation  occurs  for  all  FRNs. 

As  with  all  proposed  solutions  to  the  MTMC  scheduling  problem, 
the  optimization  technique  has  both  advantages  and  disadvantages  as 
listed  below: 

Advantages 

•  Optimxim  decisions  would  be  made  for  the  daily  operation  of 
each  origin  (highway,  rail  or  mixed)  loading  operation 

•  Minimum  ship  loads  could  be  specified  to  insure  that  all 
SPOEs  have  at  least  a  minimum  amount  of  cargo  on  hand 

to  load  a  ship.  Movements  would  be  routed  to  provide  the 
ship  cargoes,  thus  in  effect  automatically  consolidating 
at  the  POEs. 

•  Port  constraints  would  be  optimized  by  delaying  or  rerouting 
movements 

®  The  selection  of  seaports  for  every  origin  would  be  optimum, 
provided  origin  consolidation  could  be  performed. 

Disadvantages 

•  Limited  numbers  of  commodities 

•  The  requirement  for  three  programs;  one  to  create  the  input 
matrix,  a  program  to  produce  optimum  schedules,  and  a  program 
to  interpret  the  results  to  produce  the  detailed  output 
required  by  the  MTMC. 
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•  The  concept  of  the  perfect  knowledge  of  the  program  disturbs 
many  people.  Can  optimum  schedules  be  derived  from  approximate 
data?  There  is  no  possibility  that  such  a  schedule  could  be 
attained  in  the  real  world, 

•  The  scheduling  of  movements  is  still  being  suboptimized  because 
the  MTMC  could  not  optimize  the  sealift  portion  of  the  schedule. 
All  the  optimization  being  performed  by  MTMC  would  be  wasted  if 
MSC  could  not  take  advantage  of  these  optimum  schedules. 

SCOPE  OF  PROPOSED  WORK 

The  work  will  consist  of  the  tasks  described  below. 

Task  1  -  Data  Gathering 

Literature  search  and  interviews  with  experts  in  the  field. 

Task  2;  Feasibility  Assessment 

Based  on  the  results  of  Task  1  and  the  use  of  a  few  consultants,  an 
assessment  will  be  made  of  the  feasibility  of  any  of  the  new  optimization 
techniques  for  use  in  scheduling  movements.  This  assessment  will  include 
(1)  estimates  of  the  time  and  cost  to  develop  and  implement  such  an 
optimization  model,  (2)  the  input  requirements,  (3)  the  expected  outputs, 

(4)  compatibility  with  the  existing  simulation  model,  and  (5)  need,  if  any, 
of  a  new  simulation  model. 

Task  3  -  Documentation 

A  complete  written  report,  including  recommendations,  will  be 
prepared. 

EFFORT 

It  is  estimated  that  the  proposed  work  can  be  accomplished  in  about 
3  calendar  months  with  about  the  equivalent  of  2  person/months  at  an 
estimated  cost  of  $18,000.  This  estimate  includes  the  services  of 
Dr.  Peter  B.  McWhite  of  GRC  and  of  Dr.  Darwin  Klingman,  a  GRC  consultant, 
and  other  consultants. 
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APPENDIX  A 
TASKING  STATEMENT 
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The  purpose  of  this  task  order  is  to  provide  technical  assistance 
to  the  Military  Traffic  Manageinent  Command  (MTMC)  in  the  develoomant  of 
the  capability  for  the  analysis  and  scheduling  of  CONUS  movements  by 
computer  for  mobilization  and  deployment  planning  in  supoort  of 
operation  planning  or  other  special  projects. 

TASK  DEFINITION: 

1.  Provide  technical  assistance  to  MTMC  in  determining  the  approach 
to  use  to  acquire  the  desired  capability,  its  schedule,  and  cost. 

2.  Analyze  the  requiranents  of  the  MTMC  in  the  area  of  CONUS  move¬ 
ment  scheduling  in  relation  to  its  mission  and  the  requirements  placed  on 
the  Command  by  DOD  agencies. 

3.  Determine  the  existing  fiTMC  environment  within  which  the 
scheduling  program  must  operate.  This  includes  the  comouter,  ooeratinq 
system,  data  bases  and  other  available  software. 

4.  Investigate  the  applicable  mathematical  techniques  and  existing 
software  capable  of  meeting  the  requirements  for  a  CONUS  movement  scheduling 
model . 

5.  Prepare  a  formal  report  describing  the  recommended  model  functional! 
and  technically  to  include  description  of  how  the  model  addresses  discrete 
tacecs  of  MTMC  functional  requirements.  The  report  must  include  estimated 
time  and  cost  for  model  design  and  development,  or  conversion  and  modification 
in  consideration  of  subsequent  tasking  from  MTliC. 

6.  Provide  other  technical  assistance  as  requested  by  the  COTR. 


/ 


rha  anticipated  starting 


iata  cf  this  task  is  20  April  1979,  All 


technical  work  under  this  task  will  be  completed  by  12  July  1979. 


•  GENERAL  PROVISIONS: 

1.  Progress  on  this  task,  along  with  resource  consumption,  will  be 
reported  in  regular  monthly  and  special  reports  as  required, 

•  2.  A  draft  report,  docu.T:£nti ng  all  work  performed  under  this  task 
will  be  provided  to  the  COTR  in  two  copies  not  later  than  12  July  1979  and 
a  final  report  within  30  days  after  receipt  of  approved  draft  report. 


MANAGEMENT: 


DSS-W  COTR 


COORDINATION: 


MT>1C 


Mr.  William  S.  Boone  697-3686 


Peter  H.  W.  van  der  Goes  756-2150 


Major,  USAF 
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APPENDIX  B 
MAPS  DEVELOPMENT 

Extracted  from  Larry  Bobo,  "Systems  Description 
for  Mobility  Analysis  and  Planning  System  (MAPS)," 
MTMC,  1  March  1979 


APPENDIX  B 
MAPS  DEVELOPMENT 

Section  I.  Introduction 

This  section  defines  objectives,  references  and  background  for  MT-SY  Input 
to  the  MAPS  IX  Analysis  and  Design  Task  Force. 

1.  Purpose.  The  objectives  of  the  MODS  systea  description  contained  In 
this  document  are  to  describe  the  system  and  Influences  sufficiently  to  assist 
the  development  of  a  concise  Detailed  Functional  System  Requirement  (DFSR) 
for  the  eventual  design  of  a  state-of-the-art  MTMC  Mobility  Analysis  and 
Planning  System,  and  Intra— CONUS  System,  for  time— sensitive  planning  and 
interaction  with  JCS,  MAC,  MSC  and  other  Players  of  JOPS  in  the  WWMCCS  and  WIN 
environment. 

2.  following  documents  are  referenced  as 
applicable  Influence  and  guidance  for  the  MODS  systems  MAPS  and  Intra-CONUS: 

a.  JCS  Pub  6,  Vol  II,  Part  11,  Chapter  1,  DEPREP 

b.  JCS  Pub  6,  Vol  II,  Part  14,  Chapter  5,  INCONREP 

C.  NMCSSC  CSM  DM  185-75  GEOGRAPHIC  LOCATIONS  CODES  (GEOFILE) 

d.  WWMCCS  J7204-0M-DEPDA 

3.  Background.  The  Mobility  Analysis  and  Planning  System  (MAPS)  began 
with  the  concept  outlined  In  1966.  The  design,  programming  and  testing  was 
completed  by  October  of  1968  for  execution  on  a  Burroughs  5500  system  at  the 
Eastern  Area.  Testing  of  the  system,  with  Operation  Plan  (OPLAN)  MOVECAP-68, 
resulted  with  the  Command  estimate  of  approximately  1.5  saved  man-years  of 
manual  effort  for  the  MOVECAP  plan.  MAPS,  then  called  the  Military  Traffic 
Management  and  Terminal  Services  (MTMTS)  Automated  transportation  Scheduler 
(MATCH) ,  was  not  active  between  1968  and  1972  because  of  JCS  review  and 
developmental  efforts  in  the  area  of  Deployment  Reporting  (DEPREP) . 


with  the  Installation  of  a  Burroughs  5500  computer  at  the  Headquarters, 
operation  and  development  of  the  system  was  shifted  to  Che  Headquarters  in 
1972. 

From  1972  to  1973  the  system  was  used  Co  support  two  smaU-Co-medium  JCS 
plans;  JSCF-74  and  Gallant  Crew. 

During  the  period  of  December  1972  through  April  of  1973  the  system  was 
converted  to  Che  World  Wide  Military  Command  and  Control  (WWMCCS)  Honeywell 
Computer.  This  conversion  was  instrumental  in  updating  the  system  by: 

a.  accomodating  a  greatly  revised  DEFHEF  edit 

b.  moving  from  a  disk/ tape  environment  to  a  total  disk  environment 

c.  Introduction  of  the  Command  and  Control  Technical  Center  (CCTC) 
developed  Deployment  Data  (DEFDA)  file* 

d.  Introduction  of  MAPS,  vice  MATCH,  with  the  DA  approval  for  ten 
basic  enhancements;  as  follows: 


ENHANCEMENT 

COMPLETED 

(1) 

EAD-HDD  Modification 

Jun  75 

(2) 

DEPSEP  Flag  ID 

Jun  75 

(3) 

Cargo  Detail 

Jun  75 

(4) 

Shipload  Consolidation 

Apr  76 

(5) 

latra-CONTJS  "Bare  Bones" 

Aug  76 

(6) 

Cost  Model 

Deferred 

(7) 

Vehicle  Model 

Deferred 

(8) 

Port  Model 

Deferred 

(9) 

VDU  Model 

Deferred 

(10) 

Requirements  Generator 

Deferred 

Development  of  the  Joint  Operation  Planning  System  (JOFS)  by  the  Command 
and  Control  Technical  Center  (CCTC)  evidenced  the  increased  JCS  concern  in 
the  area  of  Joint  Operation  Planning.  This  Increased  Involvement  by  CINC's, 
Services  and  TOA'a  produced  more  frequent  taskings  for  MAPS  with  data  volisnes 
three  to  four  times  those  anticipated  during  the  1972-73  conversion.  The 
increased  frequency,  volume  and  complexity  caused  the  1975  deferment  of  five 
enhancements  in  order  to  develop  JSCP  FT  76  enhancements  for: 


ENHANCEMENT 

COMPLETED 

Ae 

Organic  Moves 

May 

76 

b. 

Non  Self  Deployable  Aircraft 

May 

76 

c. 

Floating  Craft 

May 

76 

d.  Refined  Cargo  Detail-Short  Tons 
Less  Than  Five 

May 

76 

e. 

Container  Ammo  Port 

Feb 

77 

f. 

Intra-CONUS  Cargo  Detail 

May 

77 

g.  Refined  Intra-CONDS  Inload 
Reports,  Service  Unique  M7MT  Tables, 
Equipment  Summary 

Sep 

78 

h. 

Comparison 

Deployment /Mob ilizat ion 

Sep 

78 

Increased  operational  demands  placed  on  MAPS  along  with  unrealistic 
milestone  for  system  enhancement  rendered  the  system  vulnerable  to  excessively 
long  execution  times,  a  near  unmanageable  state  and  a  state  of  questionable 
reliability. 

Because  of  the  commonality  of  data  between  DEFBEP  and  INCONPEF,  the  time- 
sensitive  developmental  effort  and  customer  recommendation  and  guidance,  the 
Intra-COiniS  system  was  developed  through  MAPS  program  cannibalization  where 


possible.  For  report  generation  this  approach  vaa  manageable  and  provided 
an  expedient  approach  to  providing  MAPS  like  products.  In  the  areas  of 
scheduling  and  files  updating  It  required  experimentation  which  grew  extremely 
tedious  because  of  excessive  and  Incompatible  logic  and  absent  or  unnecessary 
paramaters  and  constraints.  The  two  main  conflicts;  1)  MAPS  reverse 
scheduling  vs  Intra—CONtJS  forward  scheduling  and  2)  MAPS  outloadlng  at 
Installation/depot  vs  Intra-CONUS  Inloadlng  at  mobilization  station. 

MIMC  concern  for  more  timely  planning  response,  flexibility  In  applying 
planner  judgement,  and  the  inability  to  Intervene  during  MAPS  execution  led  to 
the  conclusion  in  August  of  1978  that  the  system  required  total  redesign. 

On  August  7,  1978  the  Vice  Commander,  MTMC  directed  the  formation  of  a 
MAPS  II  Analysis  and  Design  Task  Force  with  the  specific  objective  of 
developing  a  Detailed  Functional  System  Requirement  (DFSR)  for  a  tlme^sensitive 
Mobility  Analysis  and  Planning  System.  The  concensus  was  that  a  moratorium 
would  exist  on  the  current  MAPS  and  Intra-CONUS  enhancement  with  maximum 
priority  given  to  DFSR  and  System  development. 
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